fix: reach did not terminate on nightly, and depth alone was never going to bound it - #30

…ing to bound it

My own regression, and the way it reached main is worth writing down. #29 removed a `MethodError`
that `reach` threw on `sum(f(x) for x in xs)`. That throw was also, accidentally, a terminator.
Without it, on 1.14.0-DEV:

    reach(f, Tuple{Vector{Float64}})   # [f(x) for x in xs]   — did not return
    reach(g, Tuple{Vector{Float64}})   # sum(map(f, xs))      — did not return

Both answer in milliseconds on 1.12.2. The nightly leg is `continue-on-error`, so it could not
block the merge; I then cancelled the run that was sitting in `runtest` and a background job
merged #29 the moment `gh pr checks` reported nothing pending. The hang was on main for about
forty minutes.

`maxdepth` bounds how FAR the walk goes, not how much of it there is. Thirty-two levels branching
by sixteen candidates is not a finite amount of work in any useful sense, and `visited` only prunes
signatures that repeat — a higher-order call generates new ones. So the walk now also carries a
`maxwork` budget, shared with every subwalk, and spends `:unknown` with `why = :budget` when it
runs out. That is what `:unknown` is for; the alternative was a call that never comes back.

Shared, not per-branch, and the distinction is load-bearing: `visited` is deliberately reset in
`_subwalk` so a candidate reached under another branch is still walked here, which means `visited`
cannot also be the thing that bounds the total.

`maxwork` is a keyword on `reach`, `reach(::Module)` and `reach_script`, with the measurement in
the docstring — a caller whose entry point comes back `:unknown` with a `:budget` is in a
different situation from one that is genuinely dynamic, and only they can decide to pay for more.

The spec now pins the property that does not move between versions, because the verdict does:
`[unstable(x) for x in xs]` is `:depends` on 1.12.2 and `:unknown` on 1.14.0-DEV. What must hold
everywhere is that a caller which can reach a mark is never reported `:clean` — with a control
that the same shapes with nothing marked behind them still are, so the assertion is not satisfied
by an analysis that never says `:clean` at all.

Measured on both: 1237 assertions on 1.12.2, 1236 on 1.14.0-DEV, 190 behaviours, green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ys so

Measured while answering "what happens with several marks behind one loop": budgets between "too
small to reach any" and the default report `:depends` with one, two, … of twelve found and the
rest never walked to. The verdict is right either way; the LIST is not complete, and
`truncated = true` is the only thing that says so.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>